为什么你的工作经验不值钱
我曾经以为工作经验是以年为单位，现在才发现，打脸了—— 猪场通信与视频第一网红 脸肿码男
作为一个猪厂通信与视频年轻英俊的程序员，经常有小伙伴在后台问我：大猪厂对工作经验的要求是不是很高？工作经验少的是不是会被嫌弃没经验，工作经验太过丰富的是不是又会被吐槽没创意不活力？
是的，常见的招聘要求中，基本都有“工作经验”的要求，而且都是以年作为单位，HR似乎比较迷恋这个数字，但是实际情况却是：工作经验往往不是以年衡量的，甚至有些时候，跟时间没有关系。
今天想要分享的一点，是关于“为什么你的工作经验不值钱”，或者“怎么样才能让工作经验值钱”，庸俗，却能让每个人提起精神。
以下经验分享，仅仅适用于码农相关职位，其他职位可借鉴其思想，不可照搬。
●●●
开始
从一个小小的面试题目入手：
编写一个javscript函数 fn，该函数有一个参数 n（数字类型），其返回值是一个数组，该数组内是n个随机且不重复的整数，且整数取值范围是 [2, 32]。
如果愿意，请先暂停阅读文章，自己动手写一下这个函数，是的，老简单了。我可以等你五分钟。
~~~华丽的五分钟过去了 ~~~
现在假设你的工作时间为 y 年，经验系数默认为 1，即工作经验是：Y = 1 * y。从现在开始，以下的错误，你要是遇到了，请自行调整经验系数。
- 可用 -
作为一段需要满足需求的代码来说，它最核心的、最低的要求就是：可用。
如果你没有产出一个函数( fn )，或者产生了语法错误，那就请设置经验系数为 0，然后去面壁思过；
请将代码在控制台运行，并执行 fn(3)，看看是否输出一个数组，数组中包含了三个随机且不同且在[2,32]的整数，如果不是，请将 经验系数 * 0；
一个参考的半伪代码是：
其中 getRand 、checkInArr还另有讲究，后面会提到。当然思路和方法不止一个，后面也会提到。
有相当多的面试者，包括不少工作时间为2年以内的同学，都会在这一步犯错，非常遗憾。
- 健壮 -
代码是否老道，过了“可用”这一关后，就开始见分晓了。所谓“健壮”，即最基本的兼容性处理、边界处理，异常处理、用户输入校验。很多时候，需求方不会明确告诉你这些逻辑怎么处理（在实际开发中，似乎也比较常见），但并不意味着你不需要处理。健壮的程序，一定会将这些兼容性、边界、异常、输入做处理，以保证核心功能的正确输出。当然，如果你的代码没有任何输入并不考虑兼容性（可能吗？）或者仅仅是内部函数，那这一步要求可以降低，并不意味着你可以完全不做。
好，回过头看代码：
· 如果你没有对 n 的取值范围做校验（n必须是 1 到 31 之间的整数），请将经验系数 * 0.3；
· 如果你没有对 n 是否为数字做校验，请将 经验系数 * 0.5；
· 如果你没有对 n 是否存在做校验，请将 经验系数 * 0.7；
· 如果上述校验都做了，但是没有校验对，请将 经验系数 * 0.9；你需要多练习，仔细认真的。
一个参考的半伪代码是：
有了这些健壮性校验后，妈妈就不用担心 fn 函数死循环、语法错误以及错误的API调用了。伪代码中，校验是分为三步的，但实际代码中，完全可以合并处理，但是逻辑不能少。
- 可靠 -
大多数面试者都止步于前两关，鲜有进入第三关的：可靠。javascript没有强数据类型，函数的返回值也无法强制返回的数据格式。但是作为“可靠”的要求，尽可能在任何情况下，都返回一个可靠的结果，哪怕是异常情况下。是的，这一步很简单，几乎不耗费几个字节的代码，但是会让 fn 的返回值变得可靠：
如果你留意到并处理可靠返回值的问题，那请将 经验系数 * 1.2；
另外，一个牵涉的话题就是：异常情况下，是否要抛出 Error，或 console.error ？关于这个话题，似乎没有定论，需要自己衡量。我的观点是：如果异常情况下不会造成太大影响的话（包括定位错误），就不用抛错或提示。但同样的，这个衡量仍然是经验性的。此处不再展开讨论。
- 宽容 -
如果在你的日常开发中注意“可用”、“健壮”、“可靠”原则的话，你的工作经验就会大于你的工作时间，也就会更容易受到重视，自己所挖的坑就会少。而我近期面试的人中，甚至包括5、6年工作时间的，几乎都止步于此。
如果你要想成为一个受欢迎的技术人员，“宽容”是第一步： 对需求宽容、对用户宽容、对调用者宽容、对维护者宽容。
回到代码:
· 如果 n 是一个字符串数字，是否可以允许进入处理流程？ 如果是，请将经验系数 * 1.1；
· 如果 n 是一个含有小数的数字，比如 3.000001，是否允许进入处理流程？如果是，请将经验系数 * 1.1；
· 你的代码中，是否有足够多且清晰的注释？ 如果是，请将经验系数 * 1.2；
· 如果需求调整了 [2, 32] 的范围，你的代码是否可以快速调整，甚至不用调整？如果是，请将经验系数 * 1.2；
一个参考的半伪代码是：
- 精益求精 -
恭喜你完成了前四关，如果你在实际开发中，时时刻刻留意这些原则，这足够让你的工作经验扩大化，并给你带来更多的认可，这些认可来自于需求方（或许是那个曾经非常蛮横的产品狗）、用户以及你的同事。但，不因该包括你自己，你还需要更进一步。
宽容是宽以待人，精益求精是严以律己。内外兼修才是高手。
上文做了一点伏笔，现在讨论 getRand 、 checkInArr 到底有哪些讲究：
getRand：
· 如果你不知道 Math.random() 返回 [0, 1) 的小数，请自行翻阅js手册；
· 如果你不知道怎么将 [0, 1) 等比放大到任意区间 [min, max)，请慎重考虑是否合适做一个码农；
代码是类似这样的： Math.random() * ( max - min + 1 ) + min。 现在的问题是：如果要取整数，是向上取整，还是向下取整？
· 如果你不假思索，就回答：“都行”，那你需要去面壁思过；
· 如果你略作停顿，回答： “取整方法会影响边界设置”，那恭喜你有一些进步；
· 如果你认真思考后，回答：“只能向下取整”，那你已经走在了高手的路上。
是的，只能向下取整，这涉及“随机”概率的分布问题，请为边界值仔细考虑一下。这里不再细述。
checkInArr：
Array.prototype.indexOf 是优先方案，除非你考虑IE6（当然也可以用垫片函数给IE6加上这个indexOf）；
用 map 来作为key查询代理，这个方法简单高效，兼容性也非常好；
最不济，自己for循环。
好了，这些方案有性能差异吗？差异的分水岭在循环多少次的情况下出现？不同浏览器表现如何？能否写一个性能测试脚本，把不同方案跑上 10000 次看看？
创建一个包含 2... 32的数组，然后乱序排序(Array.prototype.sort )后，直接取前 n 个整数，是不是更高效？
还有，返回的数组要不要控制一下排序？
当 n 大于 31 时，是要返回空数组，还是全部31个数字？
当 n 为 30 的时候，遍历30次（或更多），是不是不如直接随机去掉一个更简单、更高效？
这些，就交给你了。
当你将这五个原则（可用、健壮、可靠、宽容、精益求精）变成你自己的开发习惯，你的工作经验就跟你的工作时间没有关系了。
——【特别推荐】——